Current data dial-in services permit end-users to connect their Personal Computers (PCs) and routers to a Data Service Provider (DSP). The DSP provides end-users with access to the Global Internet, and, in the case of Corporate DSPs, access to corporate intranets.
Traditionally, connectivity between end-user PCs and a DSP is achieved through the use of a PC modem, which sends packetized data by modulating an analog signal. The modem uses the Public Switched Telephone Network (PSTN) to achieve connectivity to a corresponding DSP-owned modem in a modem pool, which de-modulates the signal and routes the packetized data to the appropriate destination, based on the control information embedded in the data packet. Alternatively, connectivity may be achieved via ISDN BRI or PRI access facilities. End-user authentication, authorization, and accounting is performed by the ISP via standard techniques such as clear text password authentication, Password Authentication Protocol (PAP), or Challenge Handshake Authentication Protocol (CHAP). Once an end-user has been authenticated as a valid user, the end-user's data packets are sent to the appropriate destination (depending on the data packet's destination address), allowing the end-user to use data networking applications such as telnet, electronic mail, File Transfer Protocol (FIP), and Hyper-Text Markup Language (HTML) applications.
This arrangement has led to some problems. Network studies have shown that a typical end-user dial-in data session lasts for twenty minutes, and that some sessions remain active for hours or days. These long duration data calls can cause congestion of the PSTN, which is engineered for voice calls which are typically three to five minutes in duration. PSTN congestion results in added cost to LECs in regrading voice switches, and provisioning additional inter-office facilities (IOF) to handle the added load between voice switches.
From the DSP perspective, dial-in data services have created a different set of problems. The cost of maintaining modem pools contributes a large percentage of a DSPs operating costs. Additionally, increasing modem pool capacity requires new access lines (either single access lines or multiplexed facilities such as Primary Rate Interface ISDN or channelized T1), which require significant lead-time for the LEC to install, making it difficult for a DSP to react quickly to increasing market needs in a timely fashion.
As a solution to these problems, Local Exchange Carriers (LECs) and some Large DSPs have begun to investigate alternative connectivity options allowing end-users to access the internet or corporate intranet. These service providers create a Data Access Transport Service (DATS) through which DSPs, who subscribe to the DATS, outsource their ISDN Basic Rate Interface (BRI) and analog modem pools to an LEC or DSP (hereinafter, for simplicity, referred to as "the LEC"), who maintain a large modem pool to be shared by all subscribed DSPs. Thus, a DATS allows the DSPs to operate a Virtual Private Dial-in Network (VPDN), where calls and virtual resources to the said DSP remain private and confidential, even though the physical facilities are shared among multiple DSPs.
DATS calls, which can be recognized from the dialed number by the originating switch, can be immediately diverted to the DATS equipment via direct trunking facilities, thus removing long duration data calls from interoffice facilities, tandem and egress switches. Additionally, LECs can also implement front-end devices that recognize end-user data calls and divert the calls to DATS equipment via direct trunking facilities, thus removing such calls from the originating switch as well, effectively removing PSTN congestion due to long duration data calls.
DATS tariffs can be based on the number of logical modem ports subscribed to (which defines the maximum number of simultaneous end-users who can access that particular DSP via DATS), and the Wide Area Network (WAN) link(s) that provide connectivity between the DSP data equipment and the DATS data equipment (which defines the maximum instantaneous aggregate bandwidth available to all end-users connected to that particular DSP via DATS). End-user AAA (Authentication, Authorization, and Accounting) can be performed by the LEC on behalf of the DSP, or alternatively, the LEC can perform only partial authentication and forward on the information to the DSP via tunneling protocols such as Layer 2 Forwarding (L2F), Point-to-Point Tunneling Protocol (PPTP), or Layer 2 Tunnelling Protocol (L2TP).
The DATS does effectively remove the PSTN congestion issue, and can provide DSPs a more cost-effective arrangement than managing their own modem pool (the subscribed DSP benefits from the economy of scale provided by the LEC's DATS large modem pool). However, some issues arise with this implementation. First, the LEC providing the DATS must ensure that it can guarantee to its subscribed DSPs a pre-defined quality of service. That is, the LEC needs to guarantee that a particular DSP will have access to the number of logical ports it has subscribed to (with an agreed blocking ratio). To meet this requirement, the LEC must be able to enforce a given DSPs service quota so that, during periods of high demand, a DSP will not use more resources, or ports, than it has subscribed to, which results in lost revenue to the LEC, and may negatively impact other DSPs' service quality. This is a challenging requirement, since it involves a real-time view of all simultaneous users connected to each DSP, and the ability to refuse connectivity to a particular DSP (should a connection request exceed that DSP's service quota).
Another issue with DATS relates to the distribution of calls over multiple DSP Network Gateways (NGs). If tunneling protocols are used, a DSP may interface with the DATS via more than one Network Gateway, which terminates the tunneling protocol. In such cases, it is important that the DATS system maintain an even call distribution among the Network Gateways, such that each end-user who is connected to the DSP is provided with the same quality of service (bandwidth, delay, etc.) as other connected end-users. Additionally, a DSP may install Network Gateways of different processing power, such that it becomes important that the DATS system distribute the calls based on the processing power and bandwidth handling capability of each Network Gateway. This is a challenging requirement, since it involves a real-time view of all simultaneous users connected to each DSP's Network Gateway, and the ability to direct new data calls to specific Network Gateways, taking into account the Network Gateway's processing power and bandwidth handling capability.
An important service offering for ISDN BRI end-users is the ability to support Multilink Point-to-Point Protocol (MLP), which binds the two B-channels of an ISDN BRI connection together, giving the end-user 128 kbps of effective throughput. In order for the MLP to function, however, all associated MLP segments (known as a MLP bundle) must be sent to the same Network Gateway when a tunnelling protocol is used. However, the PSTN may route different segments of a MLP bundle to diverse DATS facilities, to different pieces of equipment that route calls to Network Gateways independently. While this is an inherent characteristic of a DATS system that improves reliability, it also makes MLP coordination a challenge. Also, some ISDN terminal adaptors can send data in a 56 kbps format (as opposed to the traditional 64 kbps format), as some LECs charge higher rates for 64 kbps ISDN calls. This can cause problems, however, as DATS equipment receiving the call would interpret the call (based on the ISDN signalling message) as an analog call, and route the call to an analog modem, which would cause the call to fail. A DATS system needs an implementation that can indicate that an incoming ISDN call is of the 56 kbps data format, so that it can treat the call appropriately.
Finally, while a DSP which subscribes to a DATS does not need to physically manage a modem pool, it loses access to vital operations information it needs for activities such as customer service, marketing, troubleshooting, forecasting, and engineering. Also, some DSPs may require some real-time service tuning (for example, changing the DSP's number of ports available). A DATS must be able to provision DSP service attributes in real-time, provide real-time access to service information for troubleshooting purposes, as well as provide a repository of past system performance, for DATS performance analysis. Since the DATS may be quite large (on the order of tens of thousands of ports), it is important for LEC operations efficiency that this information be kept in a central, easily accessed location. Also, it is sometimes necessary for the LEC and/or DSP to alter the administrative state of a DATS network element, i.e. to disallow new calls from being routed through certain network elements (for example, if software is to be upgraded), while at the same time allowing existing calls already assigned to the said device to remain unaffected (such calls would be removed when the end-user terminates the call). This poses a challenge for the LEC, as today's DATS implementations involve the distributed installation of multiple modem termination units (a modem termination unit is also known as a Network Access Server (NAS), which can typically support up to 100 multiple end-user data sessions).
Traditionally, centralized control and monitoring of data equipment is implemented using network management applications that employ standard management protocols such as Simple Network Management Protocol (SNMP). The management applications, however, were not designed for real-time service control applications, where the response time must be sufficiently low so as not to exceed either PSTN voice call timers, or end-user call response expectations.